Technology companies are increasingly investing in “software-as-a-service” (SaaS) platforms. These services provide access to shared storage (e.g., SaaS database systems) and/or computing resources to clients, or subscribers. Within multi-tier e-commerce systems, different resources may be allocated to subscribers and/or their applications from whole machines, to CPU, to memory, to network bandwidth, and to I/O capacity.
Database systems managing large amounts of data on behalf of users may receive a high volume of request traffic to access data and to manage the storage of data. Different mechanisms for structuring, arranging, or otherwise making data available may be implemented in order to service requests. Secondary indexes, for example, provide an alternative arrangement of data stored in a database system which may be accessed more efficiently for particular types of information requests. Data indexed in one fashion at a database table may be indexed in a different fashion at a secondary index.
In some database implementations, items in a secondary index may be stored in one of a number of independent partitions based on a required partition key attribute of the item. With these indexes, the user is required to designate a particular attribute in the index as the partition key at time of the index's creation, and specify the partition key in subsequent queries to the index. These requirements present a number of difficulties for the user. First, the requirement is not convenient for queries that do not need to filter on the partition key. For example, a secondary index storing pizza orders may be partitioned based on a “zip code” attribute. It is inconvenient to specify all zip code values in a query for the latest orders across all zip codes. Moreover, the partitions based on user specified partition keys may grow out of balance over time in ways that are unforeseen by the user at the time of the index's creation. In some cases, particular partition keys may dominate a data set and create hotspots in the index. These issues generally reduce the usefulness and efficiency of partitioned indexes.
While embodiments are described herein by way of example for several embodiments and illustrative drawings, those skilled in the art will recognize that embodiments are not limited to the embodiments or drawings described. It should be understood, that the drawings and detailed description thereto are not intended to limit embodiments to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope as defined by the appended claims. The headings used herein are for organizational purposes only and are not meant to be used to limit the scope of the description or the claims. As used throughout this application, the word “may” is used in a permissive sense (i.e., meaning having the potential to), rather than the mandatory sense (i.e., meaning must). Similarly, the words “include,” “including,” and “includes” mean including, but not limited to.
It will also be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first contact could be termed a second contact, and, similarly, a second contact could be termed a first contact, without departing from the scope of the present invention. The first contact and the second contact are both contacts, but they are not the same contact.